home *** CD-ROM | disk | FTP | other *** search
/ Games of Daze / Infomagic - Games of Daze (Summer 1995) (Disc 1 of 2).iso / gnuish / ginf / cfgpaper.inf (.txt) < prev    next >
GNU Info File  |  1993-09-30  |  30KB  |  521 lines
  1. This is Info file cfg-paper.info, produced by Makeinfo-1.55 from the
  2. input file cfg-paper.texi.
  3.    This document attempts to describe the general concepts behind
  4. configuration of the Cygnus Support release of the GNU Development
  5. Tools.  It also discusses common usage..
  6.    Copyright (C) 1991, 1992 Cygnus Support Permission is granted to
  7. make and distribute verbatim copies of this manual provided the
  8. copyright notice and this permission notice are preserved on all copies.
  9.    Permission is granted to copy and distribute modified versions of
  10. this manual under the conditions for verbatim copying, provided that
  11. the entire resulting derived work is distributed under the terms of a
  12. permission notice identical to this one.
  13.    Permission is granted to copy and distribute translations of this
  14. manual into another language, under the above conditions for modified
  15. versions, except that this permission notice may be stated in a
  16. translation approved by Cygnus Support.
  17. START-INFO-DIR-ENTRY
  18. * configuration: (cfg-paper).    Some theory on configuring source.
  19. END-INFO-DIR-ENTRY
  20. File: cfg-paper.info,  Node: Top,  Next: Some Basic Terms,  Prev: (dir),  Up: (dir)
  21.    This document attempts to describe the general concepts behind
  22. configuration of the Cygnus Support release of the GNU Development
  23. Tools.  It also discusses common usage.
  24. * Menu:
  25. * Some Basic Terms::        Some Basic Terms
  26. * Specifics.::            Specifics
  27. * Building Development Environments::  Building Development Environments
  28. * A Walk Through::        A Walk Through
  29. * Final Notes::            Final Notes
  30. * Index::            Index
  31.  -- The Detailed Node Listing --
  32. Some Basic Terms
  33. * Host Environments::        Host Environments
  34. * Configuration Time Options::    Configuration Time Options
  35. A Walk Through
  36. * Native Development Environments::  Native Development Environments
  37. * Emulation Environments::    Emulation Environments
  38. * Simple Cross Environments::    Simple Cross Environments
  39. * Crossing Into Targets::    Crossing Into Targets
  40. * Canadian Cross::        Canadian Cross
  41. Final Notes
  42. * Hacking Configurations::    Hacking Configurations
  43. File: cfg-paper.info,  Node: Some Basic Terms,  Next: Specifics.,  Prev: Top,  Up: Top
  44. Some Basic Terms
  45. ****************
  46.    There are a lot of terms that are frequently used when discussing
  47. development tools.  Most of the common terms have been used for many
  48. different concepts such that their meanings have become ambiguous to the
  49. point of being confusing.  Typically, we only guess at their meanings
  50. from context and we frequently guess wrong.
  51.    This document uses very few terms by comparison.  The intent is to
  52. make the concepts as clear as possible in order to convey the usage and
  53. intent of these tools.
  54.    *Programs* run on *machines*.  Programs are very nearly always
  55. written in *source*.  Programs are *built* from source.  *Compilation*
  56. is a process that is frequently, but not always, used when building
  57. programs.
  58. * Menu:
  59. * Host Environments::        Host Environments
  60. * Configuration Time Options::    Configuration Time Options
  61. File: cfg-paper.info,  Node: Host Environments,  Next: Configuration Time Options,  Prev: Some Basic Terms,  Up: Some Basic Terms
  62. Host Environments
  63. =================
  64.    In this document, the word *host* refers to the environment in which
  65. the source in question will be compiled.  *host* and *host name* have
  66. nothing to do with the proper name of your host, like *ucbvax*,
  67. *prep.ai.mit.edu* or *att.com*.  Instead they refer to things like
  68. *sun4* and *dec3100*.
  69.    Forget for a moment that this particular directory of source is the
  70. source for a development environment.  Instead, pretend that it is the
  71. source for a simpler, more mundane, application, say, a desk calculator.
  72.    Source that can be compiled in more than one environment, generally
  73. needs to be set up for each environment explicitly.  Here we refer to
  74. that process as configuration.  That is, we configure the source for a
  75. host.
  76.    For example, if we wanted to configure our mythical desk calculator
  77. to compile on a SparcStation, we might configure for host sun4.  With
  78. our configuration system:
  79.      cd desk-calculator ; ./configure sun4
  80. does the trick.  `configure' is a shell script that sets up Makefiles,
  81. subdirectories, and symbolic links appropriate for compiling the source
  82. on a sun4.
  83.    The *host* environment does not necessarily refer to the machine on
  84. which the tools are built.  It is possible to provide a sun3 development
  85. environment on a sun4.  If we wanted to use a cross compiler on the sun4
  86. to build a program intended to be run on a sun3, we would configure the
  87. source for sun3.
  88.      cd desk-calculator ; ./configure sun3
  89. The fact that we are actually building the program on a sun4 makes no
  90. difference if the sun3 cross compiler presents an environment that looks
  91. like a sun3 from the point of view of the desk calculator source code.
  92. Specifically, the environment is a sun3 environment if the header files,
  93. predefined symbols, and libraries appear as they do on a sun3.
  94.    Nor does the host environment refer to the the machine on which the
  95. program to be built will run.  It is possible to provide a sun3
  96. emulation environment on a sun4 such that programs built in a sun3
  97. development environment actually run on the sun4.  This technique is
  98. often used within individual programs to remedy deficiencies in the host
  99. operating system.  For example, some operating systems do not provide
  100. the `bcopy' function and so it is emulated using the `memcpy' funtion.
  101.    Host environment simply refers to the environment in which the
  102. program will be built from the source.
  103. File: cfg-paper.info,  Node: Configuration Time Options,  Prev: Host Environments,  Up: Some Basic Terms
  104. Configuration Time Options
  105. ==========================
  106.    Many programs have compile time options.  That is, features of the
  107. program that are either compiled into the program or not based on a
  108. choice made by the person who builds the program.  We refer to these as
  109. *configuration options*.  For example, our desk calculator might be
  110. capable of being compiled into a program that either uses infix notation
  111. or postfix as a configuration option.  For a sun3, to choose infix you
  112. might use:
  113.      ./configure sun3 -notation=infix
  114. while for a sun4 with postfix you might use:
  115.      ./configure sun4 -notation=postfix
  116.    If we wanted to build both at the same time, the intermediate pieces
  117. used in the build process must be kept separate.
  118.      mkdir ../objdir.sun4
  119.      (cd ../objdir.sun4 ; ./configure sun4 -notation=postfix -srcdir=../src)
  120.      mkdir ../objdir.sun3
  121.      (cd ../objdir.sun3 ; ./configure sun3 -notation=infix -srcdir=../src)
  122. will create subdirectories for the intermediate pieces of the sun4 and
  123. sun3 configurations.  This is necessary as previous systems were only
  124. capable of one configuration at a time.  Otherwise, a second
  125. configuration would write over the first.  We've chosen to retain this
  126. behaviour so the obj directories and the `-srcdir' configuration option
  127. are necessary to get the new behaviour.  The order of the arguments
  128. doesn't matter.  There should be exactly one argument without a leading
  129. `-' sign and that argument will be assumed to be the host name.
  130.    From here on the examples will assume that you want to build the
  131. tools *in place* and won't show the `-srcdir' option, but remember that
  132. it is available.
  133.    In order to actually install the program, the configuration system
  134. needs to know where you would like the program installed.  The default
  135. location is `/usr/local'.  We refer to this location as `$(prefix)'.
  136. All user visible programs will be installed in ``$(prefix)'/bin'.  All
  137. other programs and files will be installed in a subdirectory of
  138. ``$(prefix)'/lib'.
  139.    NOTE: `$(prefix)' was previously known as `$(destdir)'.
  140.    You can elect to change `$(prefix)' only as a configuration time
  141. option.
  142.      ./configure sun4 -notation=postfix -prefix=/local
  143. Will configure the source such that:
  144.      make install
  145. will put it's programs in `/local/bin' and `/local/lib/gcc'.  If you
  146. change `$(prefix)' after building the source, you will need to:
  147.      make clean
  148. before the change will be propogated properly.  This is because some
  149. tools need to know the locations of other tools.
  150.    With these concepts in mind, we can drop the desk calculator example
  151. and move on to the application that resides in these directories,
  152. namely, the source to a development environment.
  153. File: cfg-paper.info,  Node: Specifics.,  Next: Building Development Environments,  Prev: Some Basic Terms,  Up: Top
  154. Specifics
  155. *********
  156.    The GNU Development Tools can be built on a wide variety of hosts.
  157. So, of course, they must be configured.  Like the last example,
  158.      ./configure sun4 -prefix=/local
  159.      ./configure sun3 -prefix=/local
  160. will configure the source to be built in subdirectories, in order to
  161. keep the intermediate pieces separate, and to be installed in `/local'.
  162.    When built with suitable development environments, these will be
  163. native tools.  We'll explain the term *native* later.
  164. File: cfg-paper.info,  Node: Building Development Environments,  Next: A Walk Through,  Prev: Specifics.,  Up: Top
  165. Building Development Environments
  166. *********************************
  167.    The Cygnus Support GNU development tools can not only be built in a
  168. number of host development environments, they can also be configured to
  169. create a number of different development environments on each of those
  170. hosts.  We refer to a specific development environment created as a
  171. *target*.  That is, the word *target* refers to the development
  172. environment produced by compiling this source and installing the
  173. resulting programs.
  174.    For the Cygnus Support GNU development tools, the default target is
  175. the same as the host.  That is, the development environment produced is
  176. intended to be compatible with the environment used to build the tools.
  177.    In the example above, we created two configurations, one for sun4 and
  178. one for sun3.  The first configuration is expecting to be built in a
  179. sun4 development environment, to create a sun4 development environment.
  180. It doesn't necessarily need to be built on a sun4 if a sun4 development
  181. environment is available elsewhere.  Likewise, if the available sun4
  182. development environment produces executables intended for something
  183. other than sun4, then the development environment built from this sun4
  184. configuration will run on something other than a sun4.  From the point
  185. of view of the configuration system and the GNU development tools
  186. source, this doesn't matter.  What matters is that they will be built in
  187. a sun4 environment.
  188.    Similarly, the second configuration given above is expecting to be
  189. built in a sun3 development environment, to create a sun3 development
  190. environment.
  191.    The development environment produced, is a configuration time option,
  192. just like `$(prefix)'.
  193.      ./configure sun4 -prefix=/local -target=sun3
  194.      ./configure sun3 -prefix=/local -target=sun4
  195.    In this example, like before, we create two configurations.  The
  196. first is intended to be built in a sun4 environment, in subdirectories,
  197. to be installed in `/local'.  The second is intended to be built in a
  198. sun3 environment, in subdirectories, to be installed in `/local'.
  199.    Unlike the previous example, the first configuration will produce a
  200. sun3 development environment, perhaps even suitable for building the
  201. second configuration.  Likewise, the second configuration will produce
  202. a sun4 development environment, perhaps even suitable for building the
  203. first configuration.
  204.    The development environment used to build these configurations will
  205. determine the machines on which the resulting development environments
  206. can be used.
  207. File: cfg-paper.info,  Node: A Walk Through,  Next: Final Notes,  Prev: Building Development Environments,  Up: Top
  208. A Walk Through
  209. **************
  210. * Menu:
  211. * Native Development Environments::  Native Development Environments
  212. * Emulation Environments::    Emulation Environments
  213. * Simple Cross Environments::    Simple Cross Environments
  214. * Crossing Into Targets::    Crossing Into Targets
  215. * Canadian Cross::        Canadian Cross
  216. File: cfg-paper.info,  Node: Native Development Environments,  Next: Emulation Environments,  Prev: A Walk Through,  Up: A Walk Through
  217. Native Development Environments
  218. ===============================
  219.    Let us assume for a moment that you have a sun4 and that with your
  220. sun4 you received a development environment.  This development
  221. environment is intended to be run on your sun4 to build programs that
  222. can be run on your sun4.  You could, for instance, run this development
  223. environment on your sun4 to build our example desk calculator program.
  224. You could then run the desk calculator program on your sun4.
  225.    The resulting desk calculator program is referred to as a *native*
  226. program.  The development environment itself is composed of native
  227. programs that, when run, build other native programs.  Any other program
  228. is referred to as *foreign*.  Programs intended for other machines are
  229. foreign programs.
  230.    This type of development environment, which is by far the most
  231. common, is refered to as *native*.  That is, a native development
  232. environment runs on some machine to build programs for that same
  233. machine.  The process of using a native development environment to
  234. build native programs is called a *native* build.
  235.      ./configure sun4
  236. will configure this source such that when built in a sun4 development
  237. environment, with a development environment that builds programs
  238. intended to be run on sun4 machines, the programs built will be native
  239. programs and the resulting development environment will be a native
  240. development environment.
  241.    The development system that came with your sun4 is one such
  242. environment.  Using it to build the GNU Development Tools is a very
  243. common activity and the resulting development environment is quite
  244. popular.
  245.      make all
  246. will build the tools as configured and will assume that you want to use
  247. the native development environment that came with your machine.
  248.    Using a development environment to build a development environment is
  249. called *bootstrapping*.  The Cygnus Support release of the GNU
  250. Development Tools is capable of bootstrapping itself.  This is a very
  251. powerful feature that we'll return to later.  For now, let's pretend
  252. that you used the native development environment that came with your
  253. sun4 to bootstrap the Cygnus Support release and let's call the new
  254. development environment *stage1*.
  255.    Why bother?  Well, most people find that the GNU development
  256. environment builds programs that run faster and take up less space than
  257. the native development environments that came with their machines.  Some
  258. people didn't get development environments with their machines and some
  259. people just like using the GNU tools better than using other tools.
  260.    While you're at it, if the GNU tools produce better programs, maybe
  261. you should use them to build the GNU tools.  It's a good idea, so let's
  262. pretend that you do.  Let's call the new development environment
  263. *stage2*.
  264.    So far you've built a development environment, stage1, and you've
  265. used stage1 to build a new, faster and smaller development environment,
  266. stage2, but you haven't run any of the programs that the GNU tools have
  267. built.  You really don't yet know if these tools work.  Do you have any
  268. programs built with the GNU tools?  Yes, you do.  stage2.  What does
  269. that program do?  It builds programs.  Ok, do you have any source handy
  270. to build into a program?  Yes, you do.  The GNU tools themselves.  In
  271. fact, if you use stage2 to build the GNU tools again the resulting
  272. programs should be identical to stage2.  Let's pretend that you do and
  273. call the new development environment *stage3*.
  274.    You've just completed what's called a *three stage boot*.  You now
  275. have a small, fast, somewhat tested, development environment.
  276.      make bootstrap
  277. will do a three stage boot across all tools and will compare stage2 to
  278. stage3 and complain if they are not identical.
  279.    Once built,
  280.      make install
  281. will install the development environment in the default location or in
  282. `$(prefix)' if you specified an alternate when you configured.
  283.    Any development environment that is not a native development
  284. environment is refered to as a *cross* development environment.  There
  285. are many different types of cross development environments but most
  286. fall into one of three basic categories.
  287. File: cfg-paper.info,  Node: Emulation Environments,  Next: Simple Cross Environments,  Prev: Native Development Environments,  Up: A Walk Through
  288. Emulation Environments
  289. ======================
  290.    The first category of cross development environment is called
  291. *emulation*.  There are two primary types of emulation, but both types
  292. result in programs that run on the native host.
  293.    The first type is *software emulation*.  This form of cross
  294. development environment involves a native program that when run on the
  295. native host, is capable of interpreting, and in most aspects running, a
  296. program intended for some other machine.  This technique is typically
  297. used when the other machine is either too expensive, too slow, too fast,
  298. or not available, perhaps because it hasn't yet been built.  The native,
  299. interpreting program is called a *software emulator*.
  300.    The GNU Development Tools do not currently include any software
  301. emulators.  Some do exist and the GNU Development Tools can be
  302. configured to create simple cross development environments for with
  303. these emulators.  More on this later.
  304.    The second type of emulation is when source intended for some other
  305. development environment is built into a program intended for the native
  306. host.  The concepts of operating system universes and hosted operating
  307. systems are two such development environments.
  308.    The Cygnus Support Release of the GNU Development Tools can be
  309. configured for one such emulation at this time.
  310.      ./configure sun4 -ansi
  311. will configure the source such that when built in a sun4 development
  312. environment the resulting development environment is capable of building
  313. sun4 programs from strictly conforming ANSI X3J11 C source.  Remember
  314. that the environment used to build the tools determines the machine on
  315. which this tools will run, so the resulting programs aren't necessarily
  316. intended to run on a sun4, although they usually are.  Also note that
  317. the source for the GNU tools is not strictly conforming ANSI source so
  318. this configuration cannot be used to bootstrap the GNU tools.
  319. File: cfg-paper.info,  Node: Simple Cross Environments,  Next: Crossing Into Targets,  Prev: Emulation Environments,  Up: A Walk Through
  320. Simple Cross Environments
  321. =========================
  322.      ./configure sun4 -target=a29k
  323. will configure the tools such that when compiled in a sun4 development
  324. environment the resulting development environment can be used to create
  325. programs intended for an a29k.  Again, this does not necessarily mean
  326. that the new development environment can be run on a sun4.  That would
  327. depend on the development environment used to build these tools.
  328.    Earlier you saw how to configure the tools to build a native
  329. development environment, that is, a development environment that runs
  330. on your sun4 and builds programs for your sun4.  Let's pretend that you
  331. use stage3 to build this simple cross configuration and let's call the
  332. new development environment gcc-a29k.  Remember that this is a native
  333. build.  Gcc-a29k is a collection of native programs intended to run on
  334. your sun4.  That's what stage3 builds, programs for your sun4.
  335. Gcc-a29k represents an a29k development environment that builds
  336. programs intended to run on an a29k.  But, remember, gcc-a29k runs on
  337. your sun4.  Programs built with gcc-a29k will run on your sun4 only
  338. with the help of an appropriate software emulator.
  339.    Building gcc-a29k is also a bootstrap but of a slightly different
  340. sort.  We call gcc-a29k a *simple cross* environment and using gcc-a29k
  341. to build a program intended for a29k is called *crossing to* a29k.
  342. Simple cross environments are the second category of cross development
  343. environments.
  344. File: cfg-paper.info,  Node: Crossing Into Targets,  Next: Canadian Cross,  Prev: Simple Cross Environments,  Up: A Walk Through
  345. Crossing Into Targets
  346. =====================
  347.      ./configure a29k -target=a29k
  348. will configure the tools such that when compiled in an a29k development
  349. environment, the resulting development environment can be used to create
  350. programs intended for an a29k.  Again, this does not necessarily mean
  351. that the new development environment can be run on an a29k.  That would
  352. depend on the development environment used to build these tools.
  353.    If you've been following along this walk through, then you've already
  354. built an a29k environment, namely gcc-a29k.  Let's pretend you use
  355. gcc-a29k to build the current configuration.
  356.    Gcc-a29k builds programs intended for the a29k so the new development
  357. environment will be intended for use on an a29k.  That is, this new gcc
  358. consists of programs that are foreign to your sun4.  They cannot be run
  359. on your sun4.
  360.    The process of building this configuration is another a bootstrap.
  361. This bootstrap is also a cross to a29k.  Because this type of build is
  362. both a bootstrap and a cross to a29k, it is sometimes referred to as a
  363. *cross into* a29k.  This new development environment isn't really a
  364. cross development environment at all.  It is intended to run on an a29k
  365. to produce programs for an a29k.  You'll remember that this makes it, by
  366. definition, an a29k native compiler.  *Crossing into* has been
  367. introduced here not because it is a type of cross development
  368. environment, but because it is frequently mistaken as one.  The process
  369. is *a cross* but the resulting development environment is a native
  370. development environment.
  371.    You could not have built this configuration with stage3, because
  372. stage3 doesn't provide an a29k environment.  Instead it provides a sun4
  373. environment.
  374.    If you happen to have an a29k lying around, you could now use this
  375. fresh development environment on the a29k to three-stage these tools
  376. all over again.  This process would look just like it did when we built
  377. the native sun4 development environment because we would be building
  378. another native development environment, this one on a29k.
  379. File: cfg-paper.info,  Node: Canadian Cross,  Prev: Crossing Into Targets,  Up: A Walk Through
  380. Canadian Cross
  381. ==============
  382.    So far you've seen that our development environment source must be
  383. configured for a specific host and for a specific target.  You've also
  384. seen that the resulting development environment depends on the
  385. development environment used in the build process.
  386.    When all four match identically, that is, the configured host, the
  387. configured target, the environment presented by the development
  388. environment used in the build, and the machine on which the resulting
  389. development environment is intended to run, then the new development
  390. environment will be a native development environment.
  391.    When all four match except the configured host, then we can assume
  392. that the development environment used in the build is some form of
  393. library emulation.
  394.    When all four match except for the configured target, then the
  395. resulting development environment will be a simple cross development
  396. environment.
  397.    When all four match except for the host on which the development
  398. environment used in the build runs, the build process is a *cross into*
  399. and the resulting development environment will be native to some other
  400. machine.
  401.    Most of the other permutations do exist in some form, but only one
  402. more is interesting to the current discussion.
  403.      ./configure a29k -target=sun3
  404. will configure the tools such that when compiled in an a29k development
  405. environment, the resulting development environment can be used to create
  406. programs intended for a sun3.  Again, this does not necessarily mean
  407. that the new development environment can be run on an a29k.  That would
  408. depend on the development environment used to build these tools.
  409.    If you are still following along, then you have two a29k development
  410. environments, the native development environment that runs on a29k, and
  411. the simple cross that runs on your sun4.  If you use the a29k native
  412. development environment on the a29k, you will be doing the same thing we
  413. did a while back, namely building a simple cross from a29k to sun3.
  414. Let's pretend that instead, you use gcc-a29k, the simple cross
  415. development environment that runs on sun4 but produces programs for
  416. a29k.
  417.    The resulting development environment will run on a29k because that's
  418. what gcc-a29k builds, a29k programs.  This development environment will
  419. produce programs for a sun3 because that is how it was configured.  This
  420. means that the resulting development environment is a simple cross.
  421.    There really isn't a common name for this process because very few
  422. development environments are capable of being configured this
  423. extensively.  For the sake of discussion, let's call this process a
  424. *Canadian cross*.  It's a three party cross, Canada has a three party
  425. system, hence Canadian Cross.
  426. File: cfg-paper.info,  Node: Final Notes,  Next: Index,  Prev: A Walk Through,  Up: Top
  427. Final Notes
  428. ***********
  429.    By *configures*, I mean that links, Makefile, .gdbinit, and
  430. config.status are built.  Configuration is always done from the source
  431. directory.
  432. `./configure NAME'
  433.      configures this directory, perhaps recursively, for a single
  434.      host+target pair where the host and target are both NAME.  If a
  435.      previous configuration existed, it will be overwritten.
  436. `./configure HOSTNAME -target=TARGETNAME'
  437.      configures this directory, perhaps recursively, for a single
  438.      host+target pair where the host is HOSTNAME and target is
  439.      TARGETNAME.  If a previous configuration existed, it will be
  440.      overwritten.
  441. * Menu:
  442. * Hacking Configurations::    Hacking Configurations
  443. File: cfg-paper.info,  Node: Hacking Configurations,  Prev: Final Notes,  Up: Final Notes
  444. Hacking Configurations
  445. ======================
  446.    The configure scripts essentially do three things, create
  447. subdirectories if appropriate, build a `Makefile', and create links to
  448. files, all based on and tailored to, a specific host+target pair.  The
  449. scripts also create a `.gdbinit' if appropriate but this is not
  450. tailored.
  451.    The Makefile is created by prepending some variable definitions to a
  452. Makefile template called `Makefile.in' and then inserting host and
  453. target specific Makefile fragments.  The variables are set based on the
  454. chosen host+target pair and build style, that is, if you use `-srcdir'
  455. or not.  The host and target specific Makefile may or may not exist.
  456.    * Makefiles can be edited directly, but those changes will
  457.      eventually be lost.  Changes intended to be permanent for a
  458.      specific host should be made to the host specific Makefile
  459.      fragment.  This should be in `./config/mh-HOST' if it exists.
  460.      Changes intended to be permanent for a specific target should be
  461.      made to the target specific Makefile fragment.  This should be in
  462.      `./config/mt-TARGET' if it exists.  Changes intended to be
  463.      permanent for the directory should be made in `Makefile.in'.  To
  464.      propogate changes to any of these, either use `make Makefile' or
  465.      `./config.status' or re-configure.
  466. File: cfg-paper.info,  Node: Index,  Prev: Final Notes,  Up: Top
  467. Index
  468. *****
  469. * Menu:
  470. * ANSI:                                 Emulation Environments.
  471. * Bootstrapping:                        Native Development Environments.
  472. * Building:                             Some Basic Terms.
  473. * Canadian Cross:                       Canadian Cross.
  474. * Compilation:                          Some Basic Terms.
  475. * Cross:                                Native Development Environments.
  476. * Crossing into:                        Crossing Into Targets.
  477. * Crossing to:                          Simple Cross Environments.
  478. * Emulation:                            Emulation Environments.
  479. * Foreign:                              Native Development Environments.
  480. * host:                                 Host Environments.
  481. * Machines:                             Some Basic Terms.
  482. * Native:                               Native Development Environments.
  483. * Programs:                             Some Basic Terms.
  484. * Simple cross:                         Simple Cross Environments.
  485. * Software emulation:                   Emulation Environments.
  486. * Software emulator:                    Emulation Environments.
  487. * Source:                               Some Basic Terms.
  488. * Stage1:                               Native Development Environments.
  489. * Stage2:                               Native Development Environments.
  490. * Stage3:                               Native Development Environments.
  491. * Target:                               Building Development Environments.
  492. * Three party cross:                    Canadian Cross.
  493. * Three stage boot:                     Native Development Environments.
  494. * X3J11:                                Emulation Environments.
  495. Tag Table:
  496. Node: Top
  497. Node: Some Basic Terms
  498. Node: Host Environments
  499. Node: Configuration Time Options
  500. Node: Specifics.
  501. Node: Building Development Environments
  502. Node: A Walk Through
  503. 11662
  504. Node: Native Development Environments
  505. 12080
  506. Node: Emulation Environments
  507. 16376
  508. Node: Simple Cross Environments
  509. 18437
  510. Node: Crossing Into Targets
  511. 20045
  512. Node: Canadian Cross
  513. 22237
  514. Node: Final Notes
  515. 25063
  516. Node: Hacking Configurations
  517. 25857
  518. Node: Index
  519. 27271
  520. End Tag Table
  521.